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(57) Abstract: Facilitating the exchange of information among applications (e.g.. business support systems or operational support 
systems or a combination thereof) may involve a data object from a first application, using a first controller to route the received data 
object to a first transformer, using the first transformer to transform the data object from a first format used by the first application into 
a common format object, publishing the common format object to a communication channel, receiving a request from a subscribing 
application to subscribe to the communication channel, using a second controller to route the common format object to a second 
iranslormer, using the second transformer to transform the common format object into a data object in a second formal used by the 
subscribing application, and sending the data object in the second formal to the subscribing application. 
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INTEGRATING FNTFRPR1SE SUPPORT SYSIEMS 

Related Application 
[0001] This application claims the benefit of, and incorporates by 
reference, U.S. Provisional Patent Application No. 60/299,575, filed June 19, 
2001. 

Background 

[0002] This application relates to integrating enterprise support systems 
such as business support systems (BSSs) and operational support systems 
(OSSs). A BSS typically is a computer application with which users or other 
computer processes interact to support normal business functions. BSSs are 
used across a wide variety of industries including telecommunications, 
energy, pharmaceutical, government and the like. Examples of BSSs include 
customer relation management (CRM) applications, billing applications, 
financial applications, and provisioning applications. OSSs on the other hand 
relate to the framework of computer software and network architecture 
underlying the operation and execution of the BSSs. An application for 
monitoring and/or managing the state of a computer network is one example 
of an OSS. 

[0003] Typically, a single enterprise (e.g., a telecommunications provider) 
will maintain several BSSs and OSSs (collectively, enterprise applications) 
that need to share information or otherwise interact. For example, a 
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telecommunications provider may have a provisioning application for turning 
on/off switches to control its customers' access to telephone iine3 or other 
services, a billing application for automatically generating bills to be sent out 
to customers, a CRM application for maintaining a database of its customers 
and for dealing with service calls, complaints and the like, a financial 
application for handling general accounting functions, and a network 
management application for managing the underlying network that supports 
the various enterprise applications. 

[0004] Fig. 1 shows a conventional method of integrating multiple 
enterprise applications. As shown therein, different applications communicate 
and/or exchange data with one another through specialized point-to-point 
interfaces (e.g., application program interfaces, or APIs) designed and 
implemented specifically for certain processes operating within the two 
applications being connected. Depending on the particular enterprise and the 
types and number of enterprise applications that it maintains, the number and 
complexity of point-to-point interfaces that must be designed, implemented 
and maintained can become significant. For example, the enterprise in Fig. 1 
has eleven different applications that require at least 21 separate point-to- 
point interfaces between processes. In practice, the number of point-to-point 
interfaces required can greatly exceed the number of enterprise applications 
because any two applications may require multiple point-to-point interfaces 
between them - one for each pair of processes that need to communicate. 
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[0005] In general, implementing and maintaining such specialized point-to- 
point interfaces is time-consuming and expensive, not only because of the 
sheer number of point-to-point interfaces that may be required but also due to 
the complexity and disparity of the applications being connected. For 
example, different enterprise applications, especially those provided by 
different manufacturers, may use different programming and/or control 
languages, may rely on different data models, and generally present several 
different levels and types of incompatibilities. 

Summary 

[0006] The present inventors recognized that building and maintaining 
separate point-to-point interfaces between enterprise applications is cost and 
time inefficient. Consequently, the present inventors developed various 
systems and techniques for integrating enterprise applications using an 
underlying framework of components and tools that dramatically reduce the 
time and effort required. Implementations of these systems and techniques 
may include various combinations of the following features. 
[0007] In one aspect, facilitating the exchange of information among 
applications (e.g., business support systems or operational support systems 
or a combination thereof) may involve receiving a data object from a first 
application, using a first controller (e.g., a controller class defined in an object- 
oriented programming language) to route the received data object to a first 
transformer (e.g., a transformer class defined in an object-oriented 
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programming language), using the first transformer to transform the data 
object from a first format used by the first application into a common format 
object, publishing the common format object to a communication channel, 
receiving a request from a subscribing application to subscribe to the 
communication channel, using a second controller to route the common 
format object to a second transformer, using the second transformer to 
transform the common format object into a data object in a second format 
used by the subscribing application, and sending the data object in the 
second format to the subscribing application. 

[0008] The data object received from the first application may correspond 
to one or more of a plurality of business events. Each controller may 
correspond to an associated transformer. Each transformer may correspond 
to a unique transformation from one format to another. Transforming a data 
object from a format used by the first application into the common format 
object may involve translating the data object from a vendor-specific format 
associated with the first application to an Interface Data Language (IDL) 
object and storing the IDL object in a shared object model. The shared object 
model may be implemented as a central repository of data objects 
corresponding to business events. Transforming the data object from a format 
used by a first application into the common format object may be performed 
in response to the recognition of a business event by the first application. 
[0009] In general, facilitating the exchange of information among 
applications may be performed in accordance with a plurality of process 
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models that collectively define when information is to be exchanged among 
applications. Moreover, if requests are received from a plurality.of 
subscribing applications, then, for each subscribing application, the common 
format object may be transformed (e.g., using an associated transformer) into 
a format corresponding to the subscribing application and sent to the 
subscribing application. Publishing the common format data object to a 
. communication channel may be performed in accordance with a channel 
architecture that defines a plurality of communication channels having relative 
priorities. Transforming the common format object into a data object in the 
second format used by the subscribing application may involve retrieving a 
stored IDL format object from a central repository and translating the IDL 
object into a vendor-specific format associated with the subscribing 
application. 

[0010] In another aspect, a system for facilitating the exchange of 
information among applications may include a plurality of process models, 
each defining one or more conditions for sending a business event from an 
application to one or more other applications, a shared object model 
configured to store data objects received from applications in a common 
format, a plurality of transformer classes configured to translate data object 
from a format used by one or more applications into the common format or 
vice versa, and a plurality of controller classes configured to route data 
objects to associated transformer classes. 

[0011] The system further may include a channel architecture defining a 
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plurality of communication channels, and/or relative priorities for the channels, 
to which data objects from an application are to be published. The system 
also may include an acknowledgement class configured to exchange status 
messages among applications and/or to perform exception handling. 
[0012] In various implementations, each process model may correspond to 
a different business event, the shared object model may include a central 
repository of data objects in an Interface Description Language (IDL) format, 
each transformer class may correspond to a unique application format- 
common format translation, each controller class may be configured to route 
data objects to an associated transformer class according to a specific 
process model, and/or the transformer classes and the controller classes may 
be implemented as classes in an object-oriented programming language such 
as Java. 

[0013] One or more of the following advantages may be provided. The 
techniques and methods described here result in an end-to-end solution to 
pre-integrate CRM, billing, provisioning and other BSS and OSS systems. 
The integration hub is able to integrate virtually any type of application, 
whether pre-packaged, custom-built, legacy or other dissimilar systems. 
Accordingly, the integration of disparate systems can be accelerated with 
corresponding decreases in time, effort, cost and complexity. For example, 
both the initial development time and costs for integrating systems as well as 
the expense required for subsequent improvements and modifications can be 
reduced dramatically. As a result, an enterprise can easily and quickly 
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become fully integrated to have real time visibility and control of the business 
and customer experience. 

[0014] Moreover, the integration effort can be accelerated because the 
tasks are not started from scratch. Rather, a shared object model defines the 
data entities and the corresponding attributes. As a result, the integration 
effort is cost effective and the long-term costs associated with maintaining 
BSS and OSS systems can be reduced accordingly. 
[0015] The details of one or more embodiments are set forth in the 
accompanying drawings and the description below. Other features, objects, 
and advantages will be apparent from the description and drawings, and from 
the claims. 

Drawing Descriptions 
[0016] Fig. 1 is a block diagram showing point-to-point interfaces between 
enterprise applications. 

[0017] Fig. 2 is a block diagram showing an example of how the 
integration hub may be implemented. 

[0018] Fig. 2A shows an example definition and structure of a transformer 
class. 

[0019] Figs. 2B, 2C and 2D collectively show an example definition and 
structure of a controller class. 

[0020] Fig. 2E shows an example definition and structure of an 
acknowledgement class. 
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[0021] Fig. 3 is a block diagram showing additional details of an example 
integration hub implementation. 

[0022] Figs. 3A and 3B collectively show examples of transformer rules. 
[0023] Fig. 4 is a process flow diagram showing an example of a business 
event being generated and published by one application and subscribed to by 
another application. 

[0024] Figs. 5A-5L are business event definition tables. 

[0025] Fig. 6 is a block diagram of a channel architecture. 

[0026] Figs. 7 A and 7B shows a Channel Architecture Definition table. 

Hptailpri Description 
[0027] The present inventors have developed a framework, referred to as 
the "integration hub," for integrating BSS and OSS solutions based on an 
enterprise's particular objectives. The integration hub is built around 
enterprise application integration (EAI) middleware (specifically, 
"BusinessWare" v3.1 available from Vitria, Inc. in Sunnyvale, California) that 
provides an architectural framework, data requirements, and data conversion 
rules, which collectively facilitate the integration of "best of breed" enterprise 
applications such as CRM applications (e.g., Siebel eCommunications 2000, 
Clarify CommCenter v3.1), billing (e.g., Portal Infranet v6.1, Lucent Arbor/BP 
v9.1), and provisioning packaged systems (Architel OMS v1.6.2). 
[0028] Fig. 2 is a diagram of an example integration hub implementation. 
As shown therein, the integration hub 200 uses Vitria to provide message 
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translation 204 and facilitate the exchange of state information 202 among 
various enterprise applications 207-212 (e.g., order entry 207, order 
management 208, billing 209, provisioning 210, inventory management 211, 
fulfillment 212) and further facilitates communication and interaction among 
the enterprise applications 207-212 and various classes of end-users 213-216 
(e.g., partners 213, suppliers 214, internal users 215, customers 216). The 
integration hub 200 communicates with each of the various entities 207-216 
using a "connector" - a multi-layered software communication channel 
tailored to a specific enterprise application. 

[0029] The integration hub is implemented as a distributed collection of 
software components that interact to enable enterprise applications to 
seamlessly and easily share information in the form of "business events." A 
business event represents an abstract function or activity that is common to 
many business systems, for example, create account, create order, cancel 
order, generate invoice, etc. The integration hub facilitates exchange of 
business events among disparate enterprise applications, for example, by 
translating, or transforming, business events from one proprietary format into 
another, via a common, shared format. There are six primary building blocks 
used in implementing an integration hub instance: process models, a shared 
object model (SOM), controller classes, transformer classes, 
acknowledgement class, and the channel architecture, each of which is 
described below. 
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[0030] • Process Model - A process model defines a process of when to 
send a business event from a first enterprise application (e.g., a 
provisioning system) to one or more other enterprise 
applications (e.g., a billing system) and further defines what 
information is needed for each system. A separate process 
model is defined for each different type of business event used 
in the integration hub implementation. For example, depending 
on the specific enterprise applications involved and the 
particular objectives of the enterprise, a "cancel service" process 
model could be defined that upon detecting the creation of a 
"cancel service" business event in the CRM system will direct 
that that business event also be transformed and sent to the 
provisioning system (e.g., to turn off a telephone line) and to the 
billing system (e.g., to terminate further charges and/or generate 
a final invoice). A process model typically includes, at a 
minimum, the following components: a model server, model 
properties, business event definitions, business process object 
attribute definitions, and business process states, transitions 
and actions. 

[0031] . Shared Object Model (SOM) - The SOM is a central repository 
that represents enterprise data objects in common format - 
namely : the Interface Description Language (IDL) format. 
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Business events received from an enterprise application in a 
proprietary format are transformed into the SOM format, and 
then when needed by another enterprise application, are 
transformed from the SOM format into the proprietary format of 
the requesting application. A SOM typically includes, at a 
minimum, a list of IDL structures and structure members, a list 
of arrays (including type and size), a list of application values 
and IDL values, a mapping of values to IDL fields, a mapping of 
IDL structures to Business Events, and a mapping of Interface 
Events to Business Events. 

[0032] • Transformer Classes (or "transformers") - The transformer 
classes are Java-language classes that translate data (e.g., 
business events) from enterprise application format to SOM 
format, and/or from SOM format to enterprise application 
format. Fig. 2A shows an example of the definition and 
structure of a transformer class, 

"SIToVtAddProductTransformer." A separate transformer class 
exists for each different transformation that may need to be 
performed. For example, exchanging a business event between 
a Siebel eCommunications CRM system and a Portal Infranet 
billing system would require four separate transformer classes: 
(1) a transformer class to translate from Siebel 
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eCommunications format to SOM format; (2) a transformer class 
to translate from SOM format to Siebel eCommunications 
format; (3) a transformer class to translate from SOM format to 
Portal Infranet format; (4) a transformer class to translate from 
Portal Infranet format to SOM format. For example, in the 
embodiment of Fig. 3 (which shows an Integration Hub 
integration of four different enterprise applications), the following 
transformer classes may be used: 

SIToVtAddProductTransformer, SIToVtAddServiceTransformer, 

SIToVtAppAccLvlAdjTransformer, 

SIToVtCancelProductTransformer, 

SIToVtCancelServiceTransformer, 

SIToVtCreateAccountTransformer, 

SIToVtModifyAccountTransformer, 

SIToVtModifyServiceTransformer, 

SIToVtOrderHeaderTransformer, 

SIToVtUpdAccStatusTransformer, SLTransformer, 

VtToSIUpdPrdctStatusTransformer, 

VtToSIUpdSrvcStatusTransformer, PITransformer, 

VtToPIAcctAdjustmentTransformer, 

VtToPIAddProductTransformer, VtToPIAddServiceTransformer, 

VtToPICancelProductTransformer, 

VtToPICancelServiceTransformer, 

12 
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VtToPICreateAccountTransformer, 

VtToPIModifyAccountTransformer, 

VtToPIModifyServiceTransformer, 

VtToPIUpdateAcctStatusTransformer, ABPTransformer, 

VtToABPAddProductTransformer, 

VtToABPAddServiceTransformer, 

VtToABPApplyAcctLvlAdjmntTransformer, 

VtToABPCancelProductTransformer, 

VtToABPCancelServiceTransformer, 

VtToABPCreateAccountTransformer, 

VtToABPModifyAccountTransformer, 

VtToABPModifyServiceTransformer, 

VtToABPUpdateAccountStTransformer, OMSTransformer, 
OMSToVtProvisioningResponseTransformer, 
OMSToVtServiceStatusNotification, and 
VtToOMSRequestBroadbandTransformer. 

[0033] • Controller Classes (or "controllers") - The controller classes are 
Java-language classes that route business events to 
appropriate transformer classes. For example, if the process 
model specified that a business event generated at the Siebel 
eCommunications CRM system needs to be sent to the Portal 
Intranet billing system, one controller class would route the 
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Siebel eCommunications-formatted business event to the 
transformer that translates from Siebel eCommunications format 
to SOM format, and another controller class would route the 
SOM-formatted business event to the transformer that 
translates from SOM format to Portal Intranet format. Figs. 2B, 
2C and 2D collectively show an example of the definition and 
structure of a controller class, "PIController." In the embodiment 
of Fig. 3, for example, the following controller classes may be 
used: SIController, PIController, ABPController, and 
OMSController. 

[0034] • Acknowledgement Class - The acknowledgement class is a 

Java-language class that is used to send status messages from 
an enterprise application to one or more other enterprise 
applications and/or for exception handling. For example, each 
time a business event is received by an enterprise application, 
the receiving application invokes an acknowledgement class to 
signal either that the transfer was successful or that a particular 
error occurred. Upon occurrence of error, the acknowledgement 
class can trigger an appropriate error-handling procedure. Fig. 
2E shows an example of the definition and structure of an 
acknowledgement class, "SIAcknowledgementTransformer." 
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[0035] • Channel Architecture - The channel architecture defines the 
communication channels to which business events will be 
published and the relative priority of those channels. For 
example, the following channels are used in the integration hub 
implementation depicted in Fig. 3: AccountChannel, 
ProvisionOrderChannel, ToSiebel, Acknowledgement Channel, 
ProvisioningRequest, Provisioning Response, BillingChannel, 
ToArbor, and ToPortal. Each of the integration hub business 
events is assigned a specific channel. Further details on the 
Channel Architecture are provided below. 

[0036] Fig. 3 shows details of an example integration hub implementation. 
In this example, four different enterprise applications are integrated using the 
integration hub 300: a Portal Intranet billing application 302, an Architel 
provisioning application 304, and a Siebel eCommunications CRM application 
306 and an Arbor billing application 308. The integration hub 300 is 
comprised of a shared object model (SOM) 312, a communicator 
infrastructure 310, a channel architecture 314 and connectors 316, 317. The 
SOM 312 provides a predefined common logical model of business objects 
and events specific to a particular industry. 

[0037] The SOM 312 is an IDL representation (defined using the Vitria 
software developers' kit (SDK)) of common business entities in Vitria 
BusinessWare. These business entities include account, customer, contact, 
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order, payment, and billing information. The integration hub IDL defines the 
data format, modules, and structures of common business entities such as 
account, product, service, order, customer, payment, and contact. Enterprise 
applications generate functions that are translated into business events within 
Vitria. Vitria encapsulates the business data for these events, e.g. Create 
Customer, Add Product, Cancel Service, in an IDL format that the integration 
hub defines as the shared object model (SOM). 

[0038] The SOM 312 is used by the transformation classes, which as 
described above are a set of java-language classes that use transformation 
rules 313 to translate data from enterprise application format to SOM format 
or vice versa. In effect, the transformation rules 313 are business rules that 
translate from the specific APIs (application program interfaces) used by the 
enterprise applications into the common SOM format and vice versa. More 
particularly, the event transformation rules 313 are defined in the transformer 
classes. These java transformer classes load enterprise application data into 
Vitria business event objects. The transformers also extract data from 
business event objects and load them into enterprise application databases or 
APIs. The transformer classes operate by applying formatting and translation 
logic to the data before loading them into an application or business event. 
These translation rules include changing numeric fields to alpha numeric, 
changing status values to enumerator or Boolean values, and copying string 
or numeric fields to target string or numeric fields. The transformers include 
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exception handling and acknowledgement classes that capture errors and 
publish them to an acknowledgement channel or error log. 
[0039] The communicator infrastructure 310 provides transactional 
synchronous and/or asynchronous message structure for communicating 
between the integration hub 300 and the enterprise applications. It reliably 
transports information in a consistent format between systems by employing 
an event-driven publish-subscribe methodology via communications 
channels. The communicator 310 includes a number of channels to which an 
application can publish an event and to which another application can 
subscribe to receive the event. The communicator infrastructure used in this 
embodiment was developed by, and is available from, Vitria, Inc. of 
Sunnyvale, California. Further details on the communicator infrastructure can 
be found in documentation available from Vitria and in information at Vitria's 
website: 

http://www.vitria.com/products/businessware/eai.html 
[0040] The channel architecture 314 defines how messaging will be 
partitioned for high-performance communications. The channel architecture 
defines the communication channels that business events will be published 
to. These channels include New Order, Account, and Product. Each of the 
integration hub business events is assigned a specific channel. The 
integration hub channels are prioritized (using the priority scheme developed 
by Vitria) to ensure that business events are sent to enterprise applications in 
the correct order; e.g. Create Customer is sent to billing before Add Product. 
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Detailed documentation on the priority scheme is available directly from Vitria 
for customers and integration partners. 

[0041] The connectors 316, 317 are part of the communicator 310 and 
represent the channels for communicating between the integration hub 300 
and the enterprise applications. The communicator has two different types of 
connectors to communicate with each separate application: a publisher 
connector 317, which publishes a business event from a publishing 
application to a channel in the communicator 310, and a subscribing 
connector 316 which receives a business event from the communicator 310 
(pushed by a publisher connector 317) into the subscribing application 
connector. 

[0042] Each business event represents a logical business function. 
Sample business events include account creation, product creation, service 
modification, and product cancellation. The Create Customer business event, 
for example, originates in the CRM application, e.g. Siebel or Clarify. The 
CRM application invokes an API or changes database tables that the 
integration hub monitors. The integration hub uses its connector architecture, 
which includes controllers and transformers, to translate the enterprise data 
into a SOM format within a business event. The integration hub publishes the 
business event onto the appropriate channel. Subscribers of the event - e.g., 
billing, provisioning, process automation - subscribe to the business event 
from the channel and into their respective connectors. The connectors 
translate the SOM data into the target enterprise application's data format; 
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e.g. Portal Infranet, Architel OMS. The connector invokes an application- 
specific API to load the data into the target enterprise application. The target 
enterprise application generates an Acknowledgement business event in the 
integration hub that includes the success/failure status and result data of the 
target enterprise application's API. This Acknowledgement business event is 
published to the Acknowledgement channel for transmission to another 
enterprise application or a log file. 

[0043] Each Vitria connector 316, 317 is comprised of three different 
components: a publisher / subscriber module 318 (depending on whether the 
connector is a publisher connector 317 or a subscriber connector 316), a 
transformer 320 and a driver 322. The Vitria publisher / subscriber modules 
318 send / retrieve business events to / from the communicator infrastructure 
310. The Vitria drivers 322 provide pre-built interfaces to packaged 
applications. As with the communicator infrastructure 310, the Vitria drivers 
322 and the Vitria subscriber / publisher modules 318 used in this 
embodiment were developed by and available from Vitria, Inc., although in 
other embodiments they could be custom-developed if desired. Further 
details on the publisher / subscriber module 318 and the driver 322 are 
provided in documentation available from Vitria. 

[0044] The transformer component 320 of each connector 316, 317 
provides the execution environment for the event transformation rules 313. 
More particularly, each transformer 320 is a separate Java-language class 
that, when invoked, performs a translation function on data (e.g., a business 
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event) using methods defined by the transformation rules. A transformer rule 
is an algorithm that converts between the message formats to disparate 
applications. A transformation rule lists the fields of the related messages of 
the applications and describes how each field is related to another. Figs. 3A 
and 3B collectively show an example of the transformation rules used for the 
CRM, Billing, and middleware applications. 

[0045] In general, the integration hub provides a framework that enables a 
first application, upon having a business event created or otherwise occur 
locally (such as the creation of a new customer account by a human user), to 
publish the event to an appropriate channel in the communicator 
infrastructure, and concurrently have the event converted to a common format 
(i.e., the SOM format). At that point, any other enterprise application 
connected to the integration hub can subscribe to the channel of interest and 
retrieve the newly created event. As part of the retrieval process, the event is 
converted from the common SOM format into the APIs and fields used by the 
subscribing application. The subscribing application then can use the APIs 
and fields to undertake its own local action responsive to, or otherwise 
appropriate for, the business event generated by the first application. 
[0046] Fig. 4 shows an example of data flow during a typical sequence 
using the integration hub architecture to exchange business events between 
two applications - in this example, a Siebel eCornmuriications CRM 
application and a Portal Infranet billing application. Assume, for example, 
that a human operator creates a new customer account and a service order 
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for that account in the Siebei eCommunications CRM application running on 
node 400. Following the submission of the service order, the CRM 
Application causes the new account information to be sent in Step 1 to the 
server 402 which hosts the application's database engine. The Siebei 
Workflow Manager (a component of the Siebei application) is what performs 
this send. It is invoked to send customer information to the Integration Hub. 
Upon submission of the service order, the Siebei Workflow Manager 
determines that a new account has been created and needs to be sent to the 
Integration Hub. The Siebei Workflow Manager then goes to the Siebei 
database and retrieves an instance of a pre-defined Siebei integration object 
called "Vitria Account". The integration object tells the workflow manager 
what data to get and where to get it from, for that particular business event. 
Within Siebei eCommunications, the customer data, which comprises the 
integration object instance, is transformed into XML (extensible markup 
language) format and sent over an HTTP (hypertext transfer protocol) 
protocol to Vitria servlet 403. The Siebei source connector model 407 is a 
publisher to the Vitria servlet. 

[0047] Next, in Step 3, the Siebei source connector model 407 converts 
the XML data into an IDL format and then a transformer translates the Siebei 
IDL format into a shared object model format. The source connector 407 in 
Step 4 creates a "Create Customer" event (in the SOM format) and publishes 
it onto the channel 409, which receives Create Customer business events 
that billing applications subscribe to. The integration hub channels are 
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prioritized using Vitria's configuration tools to ensure business events are 
received in the correct order; e.g. a Create Customer business eyent is 
processed before a Add Product business event. 

[0048] Next, in Step 5, the Portal Infranet target connector 410 executing 
on node 414 subscribes to the channel 409. Next, in Step 6, a transformer 
transforms the "Create Customer" event from the SOM format into 
appropriate APIs and field lists for the Portal Infranet application. In Step 7, a 
Vitria target driver sends the APIs and field lists to the connection manager 
component 413 of the Portal Infranet application. Finally, in Step 8, Portal 
Infranet creates a new customer account within its local Account table in its 
database 415. 

[0049] The integration hub's shared object model has defined, and uses, a 
set of core business events to pass customer, product and service data 
among the various enterprises applications. The number and types of 
business events used for a given integration depend on the applications being 
integrated and the objectives of the enterprise and its users. Often, the 
business event definitions are industry-specific, for example, specific to the 
telecommunications industry, because companies in a given industry often 
use the same or similar enterprise applications in furthering their commercial 
endeavors. 

[0050] For the example of Fig. 5, in which a CRM system and a billing 
system are integrated to share information with each other, the following ten 
core business events were defined and used: 
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• Create Order - starts the provisioning and billing process of an order 
within the process models 

• Add Product - add a new product to an account or sen/ice from CRM into 
provisioning and billing 

• Add Service Instance — add a new service instance, service location, login, 
and password to an account from CRM into provisioning and billing 

• Apply Account Level Adjustment - apply account-level adjustments 
(credits and debits) from CRM into billing 

• Cancel Product — cancel an existing product from an account or service 
from CRM into provisioning and billing 

• Cancel Service Instance — cancel an existing service instance from an 
account from CRM into provisioning and billing 

• Create Customer - submission of billing, payment, and contact 
information for a new account from CRM into billing 

• Maintain Account — submission of changed billing, payment, and contact 
info for an existing account from CRM into billing 

• Maintain Service Instance — make corrections to an existing serviced 
location and password from CRM into provisioning and billing 

• Update Account Status — transfer changes to account status (active, 
suspend, closed) from CRM to billing 

• Update Product Status - as provisioning system (OMS) passes 
through its processes, the product status will be updated automatically 
in Siebel the billing system to the CRM system 
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[0051] In effect, these 10 business events define a common language for 
communicating between the Siebel eCommunications 2000 CRM , Portal 
Infranet v6.1 billing, Lucent Arbor/BP v9.1 billing, and Architel OMS 
provisioning. The integration hub effectively acts as the intermediary and 
interpreter to facilitate communication between these systems. Integrating 
additional applications into the enterprise would generally require the 
definition and use of different or additional business events specific to the 
applications under consideration. However, by defining business events that 
have general applicability to several different types of applications (e.g., 
Create Customer), business events can be re-used thus reducing the 
integration effort, expense and complexity. In general, other embodiments 
could use additional or different business events, depending on the 
applications being integrated as well as the objectives of the enterprise and 
its users. 

[0052] Figs. 5A-5L are examples of business event definition tables. 
These particular business events were defined for integrating a Siebel CRM 
system with two different billing systems: Portal Infranet and Arbor. The set 
of 12 business events defined below and in Figs. 5A-5L are sufficient to 
enable the Siebel CRM system, the Portal Infranet billing system and the 
Arbor billing system to exchange information that implements the integration 
objectives of the enterprise. The integration hub defines process models 
within Vitria that subscribe to the Create Customer, Modify Customer, Update 
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Account Status, Add Product, Add Service, Modify Service, Cancel Service, 
and Cancel Product business events. The order management pFocess 
models created in the integration hub define the process management of 
accounts, orders and services. These process models define the process of 
when to send business events to the provisioning and billing systems and 
define what information is needed for each system. As an example, the Add 
Service Instance and Add Product business events for ordering a telecom 
service (e.g., a digital subscriber line (DSL)) must first be sent to Architel 
OMS for provisioning and then to Infranet or Arbor for billing after it has been 
provisioned. The Add Product for a DSL modem can be sent directly to 
Infranet or Arbor for billing. For both examples, the process model is a 
subscriber and publisher of the Add Product business event. The process 
model subscribes to the Add Product business event after it is published by 
the CRM, e.g. Siebel, Clarify. As discussed below, the process model, in 
turn, publishes the Add Product business event to the ProvisioningRequest 
channel in Fig. 6 and/or the Billing channel in Fig. 6 based on the product 
type. 

[0053] Fig. 5A shows the definition table for the "Acknowledgement" 
business event, further details of which are set forth below. 



File Name: 
Type: 

Publisher(s): 



Acknowledgment Event 
Business Event Definition 
Billing (Arbor, Portal) 
CRM (Siebel) 

Install Service Process Model 
Modify Service Process Model 
Disconnect Service Process Model 
AcknowledgementToFile 



Subscriber(s): 
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IDL File Name: ihBusinessEvents.idl 

Business Event Name: Acknowledgment 

Description: An acknowledgement event can be created in two 
main ways: 

1 . If the translation or the transformation fails in the 
Arbor, Portal and Siebel connectors an error message is 
written to the acknowledgement log file. 

2. As Arbor, Portal and Siebel target connectors' process 
each Business Event, an acknowledgement event will be 
created from the response returned from the application. 
This acknowledgement will act as a confirmation to the 
Vitria process models that Arbor, Portal or Siebel has 
successfully processed each business event. 



[0054] Fig. 5B shows the definition table for the "Add Product" business 
event, further details of which are set forth below. 



Business Event Name: Add Product 

Description: When a new service order containing products that 
are purchased by a customer, an Add Product event is kicked 
off. This event passes the deal (i.e. component or bundle) name 
stored in the CRM as well as the name of the account that it 
should be added to. This information is sent to the provisioning 
system if the product requires provisioning. Once provisioning 
has been completed, the add product event will be sent to the 
billing system and the product is added to the appropriate 
account 



File Name: 
Type: 

Publisher(s): 



Add Product Event 
Business Event Definition 
CRM (Siebel) 

Install Service Process Model 
Modify Service Process Model 
Disconnect Service Process Model 
Billing (Portal, Arbor) 
Order Pre-Processor Model 
ihBusinessEvents 



Subscriber(s): 



IDL File Name: 
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[0055] Fig. 5C shows the definition table for the "Add Service" business 
event, further details of which are set forth below. 

File Name: Add Service Event 

Type: Business Event Definition 

Publisher(s): CRM (Siebel) 

Install Service Process Model 
Modify Service Process Model 
Disconnect Service Process Model 

Subscriber(s): Billing (Arbor, Portal) 

Order Pre-Processor Model 

IDL File Name: ihBusinessEvents 

Business Event Name: Add Service 

Description: The Add Service event occurs when a new service 
is ordered. When a new service is ordered, the CRM 
application passes the details to the billing application i.e. 
account number, service type, service instance id, password, 
effective date, and service location via Vitria IOM. Vitria IOM will 
utilize the service information to create a provisioningRequest 
event to provision the products associated with the given 
addService event. Once a product underneath the specific 
servicelnstance is complete, IOM will then send the addService 
event to the billing application and create a service instance 
under the appropriate billing account. 

[0056] Fig. 5D shows the definition table for the "Apply Account Level 

Adjustment" business event, further details of which are set forth below. 

File Name: Apply Account Level Adjustment 

Type: Business Event Definition 

Publisher(s): CRM (Siebel), Account Process Model 

Subscriber(s): Billing (Portal, Arbor) 

Account Process Model 
IDL File Name: ihBusinessEvents 

Business Event Name: Apply Account Level Adjustment 

Description: When an adjustment is applied to an account, the 
adjustment information will be sent from CRM to Billing. Account 
number, adjustment amount, and reason description will be 
passed from CRM to Vitria into Billing. 
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[0057] Fig. 5E shows the definition table for the "Cancel Product" business 
event, further details of which are set forth below. 



Business Event Name: Cancel Product 

Description: This event removes product from an account or 
service object. This event passes the information such as, deal 
or component name, product instance id, account number, and 
optionally, service type, service id (Portal login), and service 
password from the CRM to Billing through the Vitria connectors 
and Vitria IOM component. This information is sent to the billing 
system and a confirmation of delivery is then sent to an 
acknowledgement log file. 



[0058] Fig. 5F shows the definition table for the "Cancel Service" business 
event, further details of which are set forth below. 



Business Event Name: Cancel Service 

Description: The Cancel Service event cancels a service by 
changing its status from active to closed. The CRM sends the 
Cancel Service event (Including account number, service type, 
service ID, effective date, and status) to the Vitria connector 
after the service has been cancelled in the CRM. 

Upon receipt of the Cancel Service event, Vitria IOM sends a 
Provisioning Request event (CreateOrder.Request - OMS 
System Event) to Provisioning and awaits a Provisioning 
Response event (CreateOrder.Response -OMS System Event). 
Once provisioning is complete, Vitria IOM sends a Cancel 
Service event to billing. 



File Name: 
Type: 

Publisher(s): 
Subscriber(s): 
IDL File Name: 



Cancel Product (Version 1.0) 

Business Event Definition 

CRM (Siebel) 

Billing (Portal, Arbor)^ 

ihBusinessEvents 



File Name: 
Type: 

Publisher(s): 
Subscriber(s): 
IDL File Name: 



Cancel Service (Version 1.0) 
Business Event Definition 
CRM (Siebel) 

Billing (Portal, Arbor), Provisioning 
ihBusinessEvents 
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Billing receives the account number through the Vitria connector 
and it uses the account number to find the account The service 
POID is found in Portal and the service status is changed by 
invoking the ChangeStatus opcode. Within Arbor, the service 
instance id is used to call the cease function on the specific 
instance of the Service Instance object that needs to be 
cancelled. Only the service instance id (externaMd) and 
effective date will need to be passed in owier to cancel service 
within Arbor. 



[0059] Fig. 5G shows the definition table for the "Create Customer" 
business event, further details of which are set forth below. 



Business Event Name: Create Customer 

Description: The Create Customer event occurs when an order 
for a new customer is submitted. When the first order for a new 
customer is submitted, the CRM application passes the 
createAccount event into Vitria and to the Account Process 
Model. The Account Process Model will then send the 
createAccount event containing contact, payment, and billing 
information into the Billing Application. The Billing Application 
takes this information and creates an account. AH optional fields 
that were not passed from CRM application will have default 
values in the Billing application. The Billing application will 
send to Vitria a confirmation indicator message stating whether 
the Billing application has successfully created the customer or 
not. 



File Name: 
Type: 

Publisher(s): 



Create Customer Event Definition 
Business Event Definition 
CRM (Siebel) 

Install Service Process Model 
Modify Service Process Model 
Disconnect Service Process Model 
Billing (Portal, Arbor) 
Account Process Model 
ihBusinessEvents 



Subscriber(s): 



IDL File Name: 
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[0060] Fig. 5H shows the definition table for the "Modify Account" business 
event, further details of which are set forth below. 



File Name: 
Type: 

Publisher(s): 



Subscriber(s): 
IDL File Name: 



Modify Account 
Business Event Definition 
CRM (Siebel) 

Install Service Process Model 
Modify Service Process Model 
Disconnect Service Process Model 
Billing (Portal, Arbor) 
Account Process Model 
ihBusinessEvents 



Business Event Name: Modify Account 

Description: The Modify Account event occurs when a 
customer's attributes change. Account modifications include 
changes to an account's billing address, contact information, bill 
payment method, and bill cycle date. When an account's 
attributes change, the CRM tool passes the billing system 
information regarding changes to the customer account. The 
billing system takes the information and updates the customer's 
attributes. The billing application will send Vitria an 
acknowledgement message when the billing system has 
successfully updated the customer's information. Examples of 
account attribute changes are changes to: the account's name, 
the account's address, the account's contact information, the 
billing cycle, the billing currency, the bill payment type, and the 
account close day of month. Note that the currency cannot be 
changed for any account. The bill frequency, bill type, and bill 
cycle day can only be modified for non-subordinate accounts. 

[0061] Fig. 51 shows the definition table for the "Modify Service" business 

event, further details of which are set forth below. 



File Name: 
Type: 

Publisher(s): 



Subscriber(s): 
IDL File Name: 



Modify Service 
Business Event Definition 
CRM (Siebel) 

Install Service Process Model 
Modify Service Process Model 
Disconnect Service Process Model 
Billing (Portal, Arbor) 
Order Pre-Processor Model 
ihBusinessEvents 
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Business Event Name: Modify Service 

Description: The Modify Service event will take place in the 
CRM when any service information is modified. 

The information regarding the change will be sent to the Billing 
Application. There are three alternate scenarios that result in a 
modifyService event. 

1 . A new product is added to an existing Service. 

2. A product is cancelled from an existing Service, 
however there are still other active products remaining under the 
same service. 

3. A product is added and a product is cancelled 
under an existing service. 



[0062] Fig. 5 J shows the definition table for the "Service Status Notification 
Error" business event, further details of which are set forth below. 



File Name: 
Type: 

Publisher(s): 
Subscriber(s): 



IDL File Name: 



Service Status Notification 
Business Event Definition 
Provisioning (OMS) 
Product Service Model 
Install Service Process Model 
Modify Service Process Model 
Disconnect Service Process Model 
ihBusinessEvents 



Business Event Name: Service Status Notification 



Description: The purpose of this event is to send provisioning 
status information from OMS to the Vitria IOM. 



When a new service or product request is made (Provisioning 
Request Event), it is sent to OMS via the OMS Target 
Connector. A response (Provisioning Response Event) is sent 
by OMS to Vitria IOM via the OMS Target Connector. The OMS 
Source Connector will monitor the OMS database to see if there 
is any change in the status of a service or product. If there is a 
change in the status of a service or product, a Service Status 
Notification Event is created with the required parameters. The 
OMS server is accessed to obtain additional information. The 
Service Status Notification Event is then sent to Vitria IOM. The 
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Vitria IOM will create and send the Update Product Status 
Business Event to Siebel (where the CRM information will be 
updated). Once provisioning is complete, the automator will 
then trigger the billing events to Portal/Arbor (where the 
BILLING information will be updated). 



[0063] Fig. 5K shows the definition table for the "Update Account Status" 
business event, further details of which are set forth below. 

File Name: Update Account Status 

Type: Business Event Definition 

Publisher(s): CRM (Siebel) 

Install Service Process Model 
Modify Service Process Model 
Disconnect Service Process Model 

Subscriber(s): Billing (Portal, Arbor) 

Account Process Model 

IDL File Name: ihBusinessEvents 

Business Event Name: Update Account Status 

Description: The purpose of this event is to send information 
from the CRM to the Billing application when an account is 
suspended, re-activated or closed. The CRM sends the 
account ID and status to Billing through the Vitria connectors 
and the Account Process Model. When an account status is 
changed to "Suspended", "Active" or "Closed", the child 
account's status must be changed to correspond to the same 
status. The CRM application will change the child services or 
products to the "Suspended", "Active", or "Closed" status before 
the account status is changed. This is a user training issues, 
and must be incorporated in the training plan. 



[0064] Fig. 5L shows the definition table for the "Update Product Status" 
business event, further details of which are set forth below. 



File Name: 
Type: 

Publisher(s): 
Subscriber(s): 
IDL File Name: 



Update Product Status 
Business Event Definition 
Provisioning (Architel), Vitria IOM 
Vitria IOM, CRM (Siebel) 
ihBusinessEvents 
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Business Event Name: Update Product Status 

Description: When a product event is triggered it will be sent 
from Siebel to the Service Level Model. The Service Level 
Model will then send a provisioning request to the provisioning 
system (OMS). When the provisioning system receives the 
request a response will be sent back to the Service Level Model 
indicating that the request has been received. Siebel will then 
be notified in order to update the product status. Upon the 
completion of provisioning all the products OMS will send a 
Service Status Notification back to the Service Level Model. 
This will then be passed onto Siebel and the status of the 
product will be changed to complete or cancelled depending on 
the event that triggers this process. 

[0065] Fig. 6 is a block diagram of the integration hub's channel 

architecture 600. To aid in understanding the data flow involved in Fig. 6, an 

explanation for each component in this figure is provided. The Siebel 

application 602 is the CRM application where customer data originates. 

There are specific data fields required by the downstream billing systems, 

Portal Infranet 604 and Arbor 606. A "channel" is a key organizational 

concept in the publish/subscribe model in that it accepts incoming events 

from publishing applications and communicates these events to subscribers 

of that channel. Fig. 7 is a Channel Architecture Definition table that includes 

a description of each channel and the associated publisher / subscriber 

information. 

[0066] The Automator Process Model 608 is a Vitria graphical model that 
specifies application integration logic. Specifically, the automator 608 is the 
business automation component that controls the flow of data between 
systems, and ensures the timely delivery of accurate data. The OMS 
application 610 is used for provisioning purposes. The Acknowledgement 
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channel 612 handles the exception logic by recording processing errors and 
success messages in a text file (Acknowledgement^). The errpr information 
may include the name of the failed event, the name of the application for 
which the connector belongs, the error message, and a flag to denote a 
success or failure. This information is packaged within an event that is sent 
to the Acknowledgement channel 612. Business Events, as described above, 
are represented in Fig. 6 at the point of each event flow. 
[0067] The following example represents an example of data flow that may 
take place in the architecture 600 when a new customer orders a DSL 
product. The Required information will be entered into the Siebel system 602 
and once the 'Submit' button is pushed by an operator, all four events are 
sent to Vitria: one createAccount event, one orderHeader event, one DSL 
addService event, and one DSL add Product event. The events will be 
processed by the Order Processor Model and finally the Service Process 
Model. These models handle the interaction between the OMS provisioning 
system 610 and billing systems 604, 606. A provisioningRequest event is 
generated from this order as well. The provisioningRequest event is then sent 
to the OMS provisioning system 610. 

[0068] Upon receiving the request, the provisioning system 610 will send 
back a provisioningResponses for confirmation. As a result of the response 
event, Vitria will send an updateProductStatus event to the Siebel CRM 602 
in order to set the status of the product to 'Pending.' 

[0069] Once provisioning is complete, the OMS provisioning system 610 
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will send two serviceStatusNotification events to Vitria denoting the DSL 
service and it's product is now 'Active/ Vitria will then send a . 
serviceStatusNotification event to the Siebel CRM 602 denoting that the DSL 
service is active. Vitria will also send an updateProductStatus event to the 
Siebel CRM 602 to change the status of the DSL product to Active.' At the 
same time, the addservice event and addproduct event will be sent to one or 
more of the billing systems 604, 606. The orderHeader event is internal to 
Vitria and will not be sent to billing. 

[0070] The channel architecture 600 described above is a configuration of 
Vitria's native channel architecture. The integration hub has defined an 
account, product, new order, and billing channels to which business events 
are published. The account, product, and new order channels are routed to 
the composite billing channel. The account, product, and new order channels 
are prioritized to ensure that business events are sent to billing and 
provisioning in the correct order. 

[0071] Various implementations of the systems and techniques described 
here may be realized in digital electronic circuitry, integrated circuitry, 
specially designed ASICs (application specific integrated circuits), in computer 
hardware, firmware, software, or combinations thereof, or in other types of 
machines. 

[0072] A number of embodiments of the present invention have been 
described. Nevertheless, it will be understood that various modifications may 
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What fs claimed is- 

1. A method of exchanging information among applications, the 
method comprising: 

providing a plurality of transformers, each transformer corresponding to 

a unique transformation from one format into another; 

using a first transformer to transform a data object from a format 

understandable by a first application into a common format data object- 
publishing the common format data object to a communication 

channel; 

subscribing to the communication channel to retrieve the published 
common format data object; and 

using a second transformer to transform the common format data 
object into a format understandable by a second application. 

2. The method of claim 1 wherein the data object corresponds to one 
or more of a plurality of business events. 

3. The method of claim 1 wherein using the first transformer to 
transform the data object from the format understandable by the first 
application into the common format data object comprises translating the data 
object from a vendor-specific format associated with the first application to an 
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Interface Data Language (IDL) object and storing the IDL object in a shared 
object model. 

4. The method of claim 3 wherein the shared object model comprises a 
central repository of data objects corresponding to business events. 

5. The method of claim 1 wherein using a first transformer to transform 
the data object from the format understandable by the first application into the 
common format data object is performed in response to a recognition of a 
business event by the first application. 

6. The method of claim 1 wherein the method is performed in 
accordance with a plurality of process models that collectively define when 
information is to be exchanged among applications. 

7. The method of claim 1 wherein publishing the common format data 
object to a communication channel is performed by a source connector and 
subscribing to the communication channel is performed by a target connector. 

8. The method of claim 1 wherein publishing the common format data 
object to a communication channel is performed in accordance with a channel 
architecture that defines a plurality of communication channels having relative 
priorities. 
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9. The method of claim 1 wherein using the second transformer to 
transform the common format data object into the format understandable by 
the second application comprises retrieving a stored Interface Data Language 
(IDL) format object from a central repository and translating the IDL object 
into a vendor-specific format associated with the second application. 

10. The method of claim 1 in which information is exchanged among 
business support systems or operational support systems or a combination 
thereof. 

1 1 . The method of claim 1 in which at least one of the transformers 
comprises a class defined in an object-oriented programming language. 

12. The method of claim 1 further comprising providing, for each 
transformer, a controller that is configured to route data objects to an 
associated transformer. 

13. The method of claim 12 comprising routing a data object to the first 
transformer using a first controller. 

14. The method of claim 12 comprising routing the common format 
data object to the second transformer using a second controller. 
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15. The method of claim 12 in which at least one of the controllers 
comprises a class defined in an object-oriented programming language. 

16. The method of claim 1 further comprising using an 
acknowledgement class to exchange status messages among applications. 

17. The method of claim 16 further comprising using the 
acknowledgement class to perform exception handling. 

18. A method of facilitating the exchange of information among 
applications, the method comprising: 

receiving a data object from a first application; 
using a first controller to route the received data object to a first 
transformer; 

using the first transformer to transform the data object from a first 
format used by the first application into a common format object; 

publishing the common format object to a communication channel; 

receiving a request from a subscribing application to subscribe to the 
communication channel; 

using a second controller to route the common format object to a 
second transformer; 
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using the second transformer to transform the common format object 
into a data object in a second format used by the subscribing application; and 

sending the data object in the second format to the subscribing 
application. 

19. The method of claim 18 wherein the data object received from the 
first application corresponds to one or more of a plurality of business events. 

20. The method of claim 18 wherein using the first transformer to 
transform the data object from the format used by the first application into the 
common format object comprises translating the data object from a vendor- 
specific format associated with the first application to an Interface Data 
Language (IDL) object and storing the IDL object in a shared object model. 

21. The method of claim 20 wherein the shared object model 
comprises a central repository of data objects corresponding to business 
events. 

22. The method of claim 18 wherein using the first transformer to 
transform the data object from the format used by the first application into the 
common format object is performed in response to a recognition of a 
business event by the first application. 
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23. The method of claim 18 wherein the method is performed in 
accordance with a plurality of process models that collectively define when 
information is to be exchanged among applications. 

24. The method of claim 18 wherein, if requests are received from a 
plurality of subscribing applications, then, for each subscribing application, the 
common format object is transformed using an associated transformer into a 
format corresponding to the subscribing application and sent to the 
subscribing application. 

25. The method of claim 18 wherein publishing the common format 
data object to a communication channel is performed in accordance with a 
channel architecture that defines a plurality of communication channels 
having relative priorities. 

26. The method of claim 1 8 wherein using the second transformer to 
transform the common format object into a data object in the second format 
used by the subscribing application comprises retrieving a stored Interface 
Data Language (IDL) format object from a central repository and translating 
the IDL object into a vendor-specific format associated with the subscribing 
application. 
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27. The method of claim 18 in which information is exchanged among 
business support systems or operational support systems or a combination 
thereof. 

28. A system for facilitating the exchange of information among 
applications, the system comprising: 

a plurality of process models each defining one or more conditions for 
sending a business event from an application to one or more other 
applications; 

a shared object model configured to store data objects received from 
applications in a common format; 

a plurality of transformer classes configured to translate data object 
from a format used by one or more applications into the common format or 
vice versa; and 

a plurality of controller classes configured to route data objects to 
associated transformer classes. 

29. The system of claim 28 further comprising a channel architecture 
defining a plurality of communication channels to which data objects from an 
application are to be published. 

30. The system of claim 29 wherein the channel architecture defines 
relative priorities for the plurality of communication channels. 
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31 . The system of claim 28 further comprising an acknowledgement 
class configured to exchange status messages among applications. 

32. The system of claim 31 wherein the acknowledgement class is 
further configured to perform exception handling. 

33. The system of claim 28 wherein each process model corresponds 
to a different business event. 

34. The system of claim 28 wherein the shared object model 
comprises a central repository of data objects in an Interface Description 
Language (IDL) format. 

35. The system of claim 28 wherein each transformer class 
corresponds to a unique application format-common format translation. 

36. The system of claim 28 wherein each controller class is configured 
to route data objects to an associated transformer class according to a 
process model. 
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37. The system of claim 28 wherein the transformer classes and the 
controller classes are implemented as classes in an object-oriented 
programming language. 

38. Machine-readable instructions, embodied in a tangible medium or 
as a propagated signal or both, for facilitating the exchange of information 
among applications, execution of the instructions causing one or more 
machines to perform operations comprising: 

receiving a data object from a first application; 
using a first controller to route the received data object to a first 
transformer; 

using the first transformer to transform the data object from a first 
format used by the first application into a common format object; 

publishing the common format object to a communication channel; 

receiving a request from a subscribing application to subscribe to the 
communication channel; 

using a second controller to route the common format object to a 
second transformer; 

using the second transformer to transform the common format object 
into a data object in a second format used by the subscribing application; and 

sending the data object in the second format to the subscribing 
application. 
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39. The instructions of claim 38 wherein the machine-readable 
instructions comprise computer software instructions executable Joy one or 
more computer systems. 

40. The instructions of claim 38 wherein the data object received from 
the first application corresponds to one or more of a plurality of business 
events. 

41 . The instructions of claim 38 wherein using the first transformer to 
transform the data object from the format used by the first application into the 
common format object comprises translating the data object from a vendor- 
specific format associated with the first application to an Interface Data 
Language (IDL) object and storing the IDL object in a shared object model. 

42. The instructions of claim 41 wherein the shared object model 
comprises a central repository of data objects corresponding to business 
events. 

43. The instructions of claim 38 wherein using the first transformer to 
transform the data object from the format used by the first application into the 
common format object is performed in response to a recognition of a 
business event by the first application. 
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44. The instructions of claim 38 wherein one or more of the instructions 
are executed in accordance with a plurality of process models that collectively 
define when information is to be exchanged among applications. 

45. The instructions of claim 38 wherein, if requests are received from 
a plurality of subscribing applications, then, for each subscribing application, 
the common format object is transformed using an associated transformer 
into a format corresponding to the subscribing application and sent to the 
subscribing application. 

46. The instructions of claim 38 wherein publishing the common format 
data object to a communication channel is performed in accordance with a 
channel architecture that defines a plurality of communication channels 
having relative priorities. 

47. The instructions of claim 38 wherein using the second transformer 
to transform the common format object into the data object in the second 
format used by the subscribing application comprises retrieving a stored 
Interface Data Language (IDL) format object from a central repository and 
translating the IDL object into a vendor-specific format associated with the 
subscribing application. 
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among business support systems or operational support systems or a 
combination thereof. 
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Transformer Class: SIToVtAddProductTransformer 

Description: This class directs the data transformation from the Siebel 
Add Product system event to the Vitria Add Product business event The 
Siebel Controller Class will invoke this class when the Add Product system 
event is received from the Siebel Servlet Source. This class will perform 
two main functions: 

1. Invoke the SflDLBuilder class to transform data from the Siebel 
Integration Object format to IDL format (Please refer to the IDL Detail 
Design document for IDL format.) 

2. Return information in IDL format to the Siebel Controller Class to be 
published to a channel. 



Class Variables: 
Instance Variables: 
Method(s): 



Method Details 
Exception(s): 



Parameter(s): 



Event Body Parameter(s). 



Return Value(s): 



None 
None 

1. performWork 

Description: This Method will transform the 
Vitria Product business component fields 
retrieved for the Add Product system events 
to IDL fields to be published by Vitria. 

1. Type: AcknowfedgementException 
Description: This contains the account id, 
business event, external application, success 
indicator, element, element id, error message, 
bold and eventXML 

1. Name: pEventBody 
Type: EventBody 

Description: The eventBody parameter holds 
the event specifications such as the name of 
the event, and the parameters of the event. 

2. Name: pSti 

Type: SimpleTranslatorlnterface 
Description: The SimpleTranslatorlnterface 
contains the log level and is used this to write 
log messages to the appropriate log file. 
1. Name: SiebelMessage 
Type: SiebelMessage Event 
Description: The SiebelMessage parameter 
contains two sub parameters i.e., a sequence 
of Product Instance struct and attributes of 
the Siebel Message event. 
1. Name: eventBody 
Type: EventBody 

FIG. 2A 



BNSDOClD <WO 02103491A2J_> 



WO 02/103491 



PCT/US02/19675 



4/30 

Controller Class: PIController 

Description: The Portal Controller (PIController) class will be developed 
to direct the business events from Vitria to the correct transformer class. 
Each business event has a different process that needs to be performed 
to create the appropriate system events. There are two functions that this 
class performs: 

1. Directs events to the appropriate transformer class. Each business 
event will have a separate transformer class that will process the 
business event into the appropriate system event. 

2. The system event (i.e. vtOpCode event) is received back from the 
transformer class. This class will then return the event to the 
connection model to be sent to the next flow (Portal Target Flow). 

Class Variables: None 

Instance Variables: None 

Method(s): 1. getTargetEventlnterfaceList 

Description: This method is a public static 
method which will set the default input 
Event Interfaces for the Data Transformation 
flow when the PIController class is selected. 

2. getSourceEventlnterfaceList 
Description: This method is a public static 
method which will set the default output 
Event Interfaces for the Data Transformation 
flow when the PIController class is selected. 

3. targetTranslation 

Description: This method will decide what 
transformer class corresponds to the input 
event. The transformer name and event are 
then passed to the callTranslation method. 
The targetTranslation method will be a public 
method. 

FIG. 2B-1 
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Method Details 

1. getTargetEventlnterfaceList 



4. calTTranslation 

Description: This method will direct the 
event to the specified event transformer 
class and call the applicable transformer 
method. The calfTransfation method is a 
private method within this class. 

5. sourceTranslation 
Description: This method overrides the 
sourceTranslation method in the super 
class. We must include this method in the 
PIController class because it is declared as 
abstract in the BaseController. However, 
we will not perform any actual data 
manipulation at this time, so we will 
simply return null. 

6. getEventXML 

Description: This method will retrieve the 
source event, and translate it into a xml 
string. 



Exception(s): 
Parameter (s): 



Return Value(s): 



None 

1. Name: strMeihodName 
Type: String 

Description: The name of the method which 
was selected by the user within the 
Processing Tab for a Simple Transformer 
in the Vitna BW console. 

2. Name: translateParams 
Type: String[] 

Description: This parameter is not used in 
this method, but is required by Vitria BW 
to implement this method. 
7. Name: resolver 
Type: MetaResolver 

Description: The MetaResolver handles the 
switch between editable and registered 
versions of the event list. 
1. Name: eventBody 
Type: EventBody 



FIG. 2B-2 
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2. getSourceEventlnterfaceList 
Exception(s): i 
Parameter(s): 



None 

1. Name: strMethodName ' 



Type: String 

Description: The name of the method which 
was selected by theuser within the 
Processing Tab for a Simple Transformer 
in the Vitria BW console. 

2. Name: TranslateParams 
Type: StringfJ 

Description: This parameter is not used in 
this method, but is required by Vitria BW 
to implement this method. 

3. Name: resolver 
Type: MetaResolver 

Description: The MetaResolver handles the 
switch between editable and registered 
versions of the event list. 



Type: EventBody 

Description: The eventBody parameter 
holds the event specifications such as the 
name of the event, and the parameters 
of the event. 
2. Name: sti 

Type: SimpleTranslatorlnterface 
Description: Use this to write log messages 
to the appropriate log file and retrieve 
the log level. 



Return Vatue(s): 



None 



3. targetTranslation 

Exception(s): 

Parameter(s): 



None 

1. Name: eventBody 



Return Value(s): 



Name: SystemEvent 
Type: EventBody 

FIG. 2C-1 
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4. callTranslation 

Exception(s): 

Parameters(s): 



Return Vaiue(s): 

5. sourceTranslation 

Exceptions): 

Parameters(s): 



Return Value(s): 

6. getEventXML 

Exceptionfs): 

Parameter(s): 



Return Value(s): 
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None 

1. Name: eventBody 
Type: EventBody 

Description: The eventBody parameter 
holds the event specifications such as the 
name of the event^and the parameters 
of the event. 

2. Name: sti 

Type: SimpleTranslatorlnterface 
Description: SimpleTransfator to retrieve 
log level and write log messages. 
Name: SystemEvent 
Type: EventBody 

None 

1. Name: eventBody 
Type: EventBody 

Description: The eventBody parameter 
holds the event specifications such as 
the name of the event, and the parameters 
of the event. 

2. Name: sti 

Type: SimpleTranslatorlnterface 
Description: SimpleTranslator to retrieve 
logger instance and log level. 
None 
FIG. 2C-2 

None 

1. Name: sti 

Type: SimpleTranslatorlnterface 
Description: SimpleTranslator to retrieve 
logger instance and log level. 
Name: xmlEvent 
Type: String 

FIG. 2D 
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Acknowledgement Class: SIAcknowledgementTransformer 

Description: This class directs and transforms the Siebel Response 
Message that results from the completion of a Service Status 
- Notification or Update Product Status event to an Acknowledgement 
business event 

The Siebel Controller Class will invoke this class when the Siebel 
Response Message is received from the Siebel Target Driver. This class 
will perform two main functions: 

1. Transform information from a Siebel Business component 
format to an IDL format. (Please refer to the IDL Detail Design 
document for IDL format) 

2. Return information in an IDL format to the Siebel Controller Class to 
be passed to the Acknowledgement Channel. 

Class Variables: None 

Instance Variables: None 

Method(s): 1. performWork 

Description: This method will transform 
the incoming Siebel Response Message 
into IDL fields to be published in Vitria. 

Method Details 

Exception: 1. Type: AcknowledgementException 

Description: This contains the account 
id, business event, external application, 
success indicator, element, element id, 
bpid, and eventXML 

FIG. 2E-1 
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Parameter(s): 1 . Name: pEvehtBody 

Type: EventBody 

Description: The eventBody parameter 
holds the event specifications such as 
the name of the event, and the 
parameters of the event. 
2. Name: pSti 

Type: SimpleTranslatorlnterface 
Description: Use this to write log 
message to the appropriate log file. 

incoming Siebel 

Resu/tsEvent Body Parameters: 1. Name: status 

Type: String 

Description: The status field is either 
Success or Error, indicating whether 
the event was processed correctly. 
2. Name: error 
Type: String 

Description: The error field contains 
any error message that occurred while 
processing the Siebel operation. 
Return Values: 1. Name: eventbody 

Type: EventBodyf] 

FIG. 2E-2 
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Transformer Rules for Account 



IDL 


Siebel 


Portal 


Field Name 


Integration 
ObjectField 
Name 


Transformation 
Me(SltolDL) 


Flist Hierarchy • 


Transformation 
Rule (IDL to PI) 


account.gfoup.name 


R2Vitria 
Account 


NIA 


HIA 


NIA String 


accountgroup.description 


R2Vitria 
Account 


NIA 


NIA 


■NIA String 


accountgfQup.staws 


R2Vitria 
Account 


Transfor- 
mation 
to common 
value 
(see IDL 
doc) 




String to 

Integer 

Transform 

to COM 

LOV(see 

IDLdoc) 


accouninewoiaws 


R2Wia 
Account 


Transform 

to COM 

LOV(see 

IDLdoc) 


0 

PIN FID STATUSES 
ARRAY [0] 
1 

PIN FLD STATUS 
ENUM[0] 


String to Integer, 

thpn acc/Vrn in 
iiiuu Qooiyii lu 

appropriate member 
ofenumlist,asper 
theCOMLOV 
(see IDL doc) 


accountaccountld 


R2Vitria 
Account 


NIA 


OPIN FLD BILUNFO 
ARRAY [0] 
1 

PIN FLD ACCOUNT 
NOSTRIOJ 


NIA 










accountbilllnfo.payH/lethod 


R2Vitria 
Hccouni 


Transform 

in 
10 

common 
value 
(see IDL 
doc) 


OPIN_FID_BILUNFO 

ADDAV ffll 
Annfxt [Uj 

1 

PIN FLD BILL TYPE 
ENUM[0] 


String to Integer, 
wen assign to 
appropriate member 
ofENUMIist. Note: 
This field is used to 
determine whelm 
or not the account is 
subordinate or not. 
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accountbillinfo.billMedia 


R2Vitria 
Account 




OPIN FID PAYINFO 
ARRAY [OJ 
1 

PIN FLO INHERITED 
INFOSUBSTRUCT 
101 

2 ~ 

PIN FLD INV INFO 
ARRAY [0] 
3 

PIN FLD DELNEffl 
PREFER STR[0] 


Vitriamust 
translate the 
paper type to 
enumerator 


accountparentld 


R2Vitria 
Account 


HjA 


i\ r\ t» t r~t r> nil f iupa 

OPIN FLD BILUNFO 
ARRAY 10 f 
1 

PIN FLD PARENT 
POID [Of 


Wis value will 
be used to 
retrieve parent 
id from 
portal 


accountbiilinfo.currency 


R2Vitria 
Account 


Transform 
to COM 
LOV(see 
tBl doc) 


OPIN FLD BILUNFO 
ARRAY [Of 
1 

PIN FLD CURRENCY 
INT 10] 


String to Integer 
Transform to 
COMLOV 
(seelDLdoc) 
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accountbilllnfoMIFrequency 


R2Vitria 
Account 


NIA 


OPIN FLD BILUNFO 
ARRAY [Of 

i 

PIN FLD BILL WE 
NINTfOj 


Convert string to 
ENUM value 
(seelDL) 


accountcontactlnfo.salutation 


R2Vitria 
Account 


NIA 


0 

PIN FLD NAMEINFO 
ARRAY [OJ 
1 

PIN FLD SALUTAW 
NSTR[0] 


NIA 
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accountcompanyName 


R2Vitria 
Account 


Limit 
to 56 
char 
in GUI 


0 

PIN FLD NAMEINFO 

ARRAYIO] 

1 

PIN FLD COMPANY 
STRfO] 


Nik 


accountcontactlnkhomePhone 


R2vitria 
Account 


HIA 


o - 

PIN FLD NAMEINFO 

ARRAY[0] 

1 

PIN FID PHONES 

ARRAY[O...N] 

2 

PIN FID TYPE 

ENUMfO] 

2 

PIN FLD PHONE STR 
101 


In addition, 
convert field 
name to 
type (i.e. 
home, work, 
cell) 


accomtaccowtType 


R2Vitfia 
Account 


Wing 

Aggregator^ 
Unbillable 
Wing' 
= Billable 


0 PIN FLD BIUJNFO 

ARRAY[0] 

1 

PIN FLD BILL TYPE 
ENUM[0] 


Convert string 
toENUM 
value 
(seelDL) 


accountbilllnfo.ccardExpire 
Date 


R2Vitria 
Account 


Transform 
to 

common 
date 

fnrmzt 


OPIN FLD PAYINFO 
ARRAY [Of 
1 

PIN FLD INHERTIED 
INFO SUBSTRUCT 

10] 
2 

PIN FLD CO INFO 

ARRAY[0] 

3 

PIN FLD DEBIT EXP • 
STR(0] 


Can only 

accept 

MM/YY 
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Se- 
quent 


' System Event 


Appli- 
cation 


Description 


1 


Add Product 


Siebel 


The "Add Product" event will send (service element) 
information to Vitna. This event is triggered in the CRM 
application when the "Submit' order button is pressed 
for an order. A Siebel workflow sends the necessary 
account information to Vitna XML format via an HTTP 
protocol. — 


2a.1 


CreateOrderRequest 


OMS 


Vitria sends a ProvisionRequest to OMS through the 
OMS target connection model which then translates it 
into a CreateOrder. Request event 


2a.2 


CreateOrder.Response 


VMS 


Upon provisioning, the OMS source connection model 
receives a CreateOrder. Response event from OMS 
which is then translated into a ProvisionResDonse. 


2a.3 


ServiceStatusNotification 


OMS 


OMS will also send to Vitria a ServiceStatusNotification 
event indicating the status of the account related to the 
ProvisionRequest. 


OK 1 

3b. 1 


Find Customer 


Portal 


As a result of the Add Product system events, Vitna 
receives an account number. Portal uses the account 
number and the opcode 

PCM_OP_CUSTJIND to determine the poid of the 
account that is getting new products added. 


3b.2 


Find Service 


Portal 


If CRM does not send Portal service information for this 
business event, Infranet assumes the deal was intended 
to be attached at the account level, not at the service 
level. If CRM sends portal service information, it will 
be necessary to retrieve the service poid in order to 
attach the product to that service. Portal uses the 
Service Type, Service Login, Account ID and the opcode 
PCMJP JEARCH to determine the poid of the service. 
*Note: If CRM fails to send service information for a 
defined service-level deal, Portal will send back an 
error to Vitria. 


Oh 0 


rind Deal 


Portal 


This system event uses the deal name to call the 
opcode PCM_OP_CUST_POL_GETJEALS. This 
will retrieve all the' deals That ire available. Internally, 
the wrapper opcode will iterate through each of the 
deals in order to match it to the deal's name. 
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Se- 
quence 


System Event 


Appli- 
cation 


Description 


3b.4 


Add Deal 


Portal 


The final opcode that may be called is PCM OP 
BILLJURCHASEJEAL. This opcode will take the 
account poid, dei poid and optionally the service 
poid. This information will be used to add new deals 
to the account/service specified. 


3b.5 


Acknowledgement 


Portal 


A response will be sent back from the Portal to Vitria 
indicating if the product has been successfully added 
or not. Vitna-IOM will transform this Acknowledgement 
event into an ServiceStatusNotification event to send 
to Siebel. 


4c.1a 


Insert Account Component 


Arbor 


The insert account component event will be called 
when anew component is added at the account level. 
The component will be associated at the account 
level, and attached to the dummy package. 


4c.1b 


Insert Service Component 


Arbor 


The insert service component will be called when a 
new component is added to an account at the service 
level. The component will be associated to the 
service instance. 


4c.2a 


Activate Account 
Lomponent 


Arbor 


Once the account component has been inserted into 
the database, it must be activated individually in the 
activate APIs before billing can begin. Each component 
must be activated individually. 


4c.2b 


Activate Service 
uomponeni 


Arbor 


Once the service component has been inserted into 

thf\ r/ofinOPA rv>no^ h/\ i/t^ii/n^/i rl in/V n it ni mint in ■fhn 

we uaiauase, itmusiue aciivateo moiviuuaiiy in me 
activate APIs before billing can begin. Each component 
must be activated individually. 


4c.3 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating that the component has been successfully 
entered or not. An acknowledgement event will be 
sent to the acknowledgement channel. 
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Se- 
quence 


System Event 


Appli- 
cation 


Description 


1 


Add Service 


Siebel 


The 'Add Service" event will send service instance 

* 9 9 *r a 'MM w * w § V V W T VI # L Villi Uwt/U Wwf r (L>U ll / WlUf / vv 

information to Vitria. This event will be triggered in the 
CRM application when the "Submit order button is 
pressed for an order. A Siebel workflow sends the 
necessarv account information to Vitria XMI format 
via an HTTP Protocol. 


2a.1 


Insert Service 
Instance 


Arbor 


The service instance event will create a new instance 
of a service instance obiect and will awociafp thp 
sewce //?ste /cf awtf a semce /ocafe/? to a billing 
account. 


2a.2 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicatinn if the service has hppn wrrpwfiilh/ 

IIIUHjuutly II ll/v Owl vlvv IIQd K/vvll OUKAjvOOl Uily 

entered or not. 


3b.1 


Find Customer 


Portal 


As a part of the Add Service system event, CRM passes 
the Account ID to Vitria. The wrapper opcode uses the 
Account ID and the opcode PCM_OP_CUSTJIND 
to determine the account POID. 


3b.2 


Create Service 


Portal 


The Create Service Portal system event will occur only 
after al 1 of the products associated with that service 
have been provisioned (forl-Hub R3.0, 10 products will 
be provisioned by OMS, all other products provisioning 
status will be defaulted) and the associated account 
has been sent to Portal. 

Once the account POID (account identifier) has been 

rppphfprl h\f Pnrfal the wrannpr nnrn/ip rails 
i\juuiv\jU uy rui LQij o/c? majyj/ov ujl/uUuc? oa//o 

PCMJPJMSTJREATEJERVICE to create a service 
instance in the intranet dalabase. 


3b.3 


Acknowledgement 


Portal 


A response will be sent back from the Portal to Vitria 
//jd/catf/jg //tf?e se/y/ce has been successfully entered 
ornot. 


4 


NIA 


IOM 


Vitria IOM will utilize the information within the 
addService event to create a ProvisioningRequest 
event to be sent to the Provisioning system. 
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Se- 
quence 


System Event 


Appli- 
cation 


Description — j 


1 


Add Account Level 
Adjustment 


Siebel 


The "Apply Account Level Adjustment" event sends 
account adjustment information-credits and debits- 
from Siebel to Vitria. This event will be triggered when 
the Account Level Adjustment applet is committed in 
Siebel. The Siebel Workflow sends the account level 
adjustments to Vitria in XML format through HTTP 
protocol. 


2a 


Find Customer 


Portal 


Portal uses the account number in the opcode 
PCM OP OUST FIND to determine the account POID. 


2b 


Apply 
Adjustment 


Portal 


The adjustment amount, account POID, and reason 
description are passed into PCMJPJILLJCCOUNT 
ADJUSTMENT to apply the adjustment to Ihe account. 


2c 


Acknowledgement 


Portal 


A response will be sent back from Portal to Vitria 
indicating whether the adjustment has been 
successfully applied or not. 


3a 


Apply Acct 
Level Adj 


Arbor 


This event will be used to apply a credit adjustment to 
an accounts overall charges within Arbor. The 
account-level adjustment will be made by creating the 
Adjustment API object and calling the Insert Misc 
function to apply the credit to the appropriate account. 


3b 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating whether the adjustment has been 
successfully applied or not. 
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Se- 
quence 


System Event 


Appli- 
cation 


Description 


1 


Cancel Deal 


Siebel 


The "Cancel Product" will be triaaeredto send 
information to Vitria when a deal has been cancelled 
either by clicking "Cancelled" button or by changing the 
status field in Siebel. Siebel Workflow sends necessary 
product information to Vitria in XML formal fhmnnh 
HHP protocol. 


2a 


Find Customer 


Portal 


As a result of the Cancel Product system event, Vitria 
receives as account number. Portal uses the account 
number in the opcode PCM_OP_CUST FIND to 
determine the account PCIIfT ~ 

UUlVf 1 1 Hit Kj UlV UUUvUf/( 1 \JiLJ . 


2b 


Read Acct Products 
(Replacing Find Deal) 


Portal 


The wrapper opcode uses the partial poid of the 
account object to call 

PCH/IJ)P_CUSTJEAD_ACCT PRODUCTS (replacing 
GET 'DEALS) to determine the'account deals and node 
location < 


2c 


Cancel Product 


Portal 


Pass the account POID, deal POID, effective 
cancellation date, and (optional) service POID to 

PCM OP BILL CANCEL DEAL tn ranrpl thp dpal at 

the account or service level. Default date to the correct 
effective date. 


2d 


Acknowledgement 


Portal 


A response will be sent back from Portal to Vitria 
indicating whether the deal has been successfully 
cancelled or not. 


3SL1 


Cease Account 
Component 


Arbor 


This event will be used to cancel an instance of a 
component that is associated at the account level 
within Arbor. The cease function is used to cancel the 
unique occurrence of the Product Package Account 
Component API object. 


3a.2 


Cease Serv Inst 
Component 


Arbor 


This event will be used to cancel an instance of a 
component that is associated at the service instance 

IpupI within Arhnr Thp ophqp fimotinn ic hqpH in nonnol 

the unique occurrence of the Product Package Service 
Instance Component API object 


3b 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating whether the deal has been successfully 
cancelled or not 


4 


NIA 


IOM 


Vitria IOM will utilize the cancelProduct information 
to create a provisioningRequest event to ensure the 
proper provisioning tasks are completed to disconnect 
the product. 
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Se- 
quence 


System Event 


Appli- 
cation 


Description 


1 


Cancel Service 


Siebel 


The "Cancel Service" event will be triggered to send 

ullUllllallUJI LU VlUla WIIuli UIV UalfUul UUilull Jul Ulal 

service is clicked in Siebel. A Siebel Workflow sends 

lllu lluLVboaiy qLCOUiII llliUllllclllun 10 vliila III AIVIL 

format via an HTTP protocol 


9a 


KjI CCKC/U/ UtJ/.n UifUUOl 


QMS 


Vitria <?pnrf<? p Prpafpflrrlpr Rpmipst (Prnufcinninn 

Request) event to OMS with the expectation of a 
CreateOrder.Response (ProvisioningResponse) event 

fnllnwpfi h\t % QpnfippQtotnQMntifimfinn P\ipni 


2b 


CreateOrder.Response 


OMS 


A CreateOrder.Response (ProvisioningResponse) will 
be sent back from OMS to Vitria - See step 2b above. 


On 


rina customer 


rortai 


rortai uses tne account number in tne opcode 
PCM OP CUST FIND to determine the account POID. 


3b 


CustReadAcct 

rfOullCtS 


Portal 


PCM_pP_CUST_READ_ACCT_PRODUCTS uses the 
partial poio ot tne account object to determine tne 
hierarchy of services. 


3c 


Cancel Service 


Portal 


Pass the account POID, service POID, effective date, 

ofafi/e onrl efahie fhne tn DPM flD T//CT OCT OTflTJIO 

siaws, anu siaius nags w rumjjr_LUoi _oti _oihiuo 

to cancel the service. 


3d 


Acknowledgement 


Portal 


A response will be sent back from Portal to Vitria 

///u/Gao//y Wllclllcl lllc bcl V/Gc llab Uccll bUULubolUliy 

cancelled or not. 


4a 


Cease Service 
Instance 


Arbor 


This event will be used to cancel a service instance 
within Arbor by calling the cease function on the unique 
occurrence of the service instance object. 


4b 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating whether the service has been successfully 
cancelled or not. 



FIG. 5F 



BNSDOCID. <WO 02 1 0349 1 A 2_ J. > 



WO 02/103491 



PCT/US02/19675 



22/30 



Se- 
quence 


System Event 


Appli- 
cation 


Description 


i 
1 


Create Account 


Siebel 


The "Create Account" event will be used to send account 
information from Siebel to Vitria. The Create Account 
event is triggered in Siebel when the "Submit" order 
button is pressed for a new customer. A Siebel 

wnrkflnw $Pftfi$ thp nPPPSSUn/ ZMwnnnt infnrmatinn tn 
vvuiiuiuw ouiiuo u/c iicucoogiy qHjUUIH llliuilllaliuil lu 

Vitria in XML format via an HTTP protocol. 




III be I IHLLUUIIL 


Arhnr 


mis eveni wm oe useojo construct tne account within 
Arbor overeating the acctAPI object and using the 

inQPrt fi in Minn tn wrifp thp snnnnnt infnrmotinn tn tha 
Mow L lUilUUUH LU WIILv Lite auUUUIIL liliUllllaUUfl 10 If 16 

appropriate Arbor database. 


2a.2 


Insert Product 
Package 


Arbor 


Add a product package to an existing account. 


2a.3 


Activate Product 
Package 


Arbor 


Activate the product for the account. 




insert lax 
Exemption 
Info 


Arbor 


Tax exemption information is set for the account by 
populating the Tax Exemption API object and calling the 
insert function to write this information to the 
appropriate Amor oataoase. mere are jour tax 
exemptions, one each for federal, state, county 
and city. 


2a.5 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating whether the account has been successfully 
createo or not. 


2b. 1 


Find Parent 
(Find Customer) 


Portal 


If a parent account number is passed across the Vitria 
interface, then the wrapper opcode will invoke 
PCM Or CUST FIND in order to establish the poid 
value'of fife parent account. This event will also 

fiptprminp whpthpr thp narpnt ic o mpmhpr nf o nrntm 
UuLulllllllc WIloLllul Lllc jJalullL lo a illulllUul Ul a ylUUjj, 


2b.2 


Commit Customer 


Portal 


Once all of the poids have been retrieved based on the 
information passed from the Vitria interface, the 
wrapper opcode calls PCM OP CUST COMMIT 

PllftiflMFti in nr/ipr tn InsfT sllThp nPwmiQtnmpT 

information into the intranet database. 


2b. 3 


Move Member 


Portal 


If the account is a non-Master account, then the 
wrapper opcode will call PCM OP_BILLJSROUP_ 

MfiUP MhMRFR tn ZQQnristplhp 7hilH ahnnnnt "" 
IrlUVE ItiLlrlDLn LU aooUUcLLu Ulu UIIIU aLLUUIIL 

to a patent account. 


2b.4 


Set Tax info 


Portal 


When present, tax exemption information is passed 

with thp snnnnnt P/1ID anrt oocnnhtpH with iho 
mUl lllu auUUUIIL rulU allu aoouUaLuU mill IMS 

accountwiththePCM OP CUST SET TAXINFO 

opcode. (Tax exemptions are notTn scope for R3.0) 


2b. 5 


Acknowledgement 


Portal 


A response will be sent back from Portal to Vitria 
indicating whether the account has been 
successfully created or not. 
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Se- 
quence 


System Event 


Appli- 
cation 


Description 


1 


Modify Account 


Siebel 


The "Modify Account event will be-used to send 
changes to a customer's attributes from Siebel to 
Vitria. Me: Currency cannot be changed for any 
account. The Modify Account event is triggered in 
Siebel when a customers account information is 
modified. A Siebel workflow sends the necessary 
account information to Vitria in XML format via an 
HTTP protocol. 


2a. 1 


Update Account 


Arbor 


This event will be used to update contact, billing, 
address, credit card, and other account related 
information for an existing account in Arbor. 


2a.2 


Update Tax 
Exemption Info 


Arbor 


This event will be used to update tax exemption 
information in the appropriate Arbor database. There 
are four tax exemptions, one each for federal, state, 
county, and city. 


2a.3 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating whether the account has been successfully 
modified or not. 


2b. 1 


Find Customer 


Portal 


This event pulls the Account ID from Vitria. Once this 
information has been received, the opcode 
PCM_OP_CUSTJIND is called to determine the POID 
of the account. 


2b.2 


Update Customer \ 


Portal 


Once the account POID has been retrieved this 
event calls the opcode 

PCM_OP_CUST_UPDATE_CUSTOMER in order to 
make any applicable updates to the customer 
information into the Infranet database. 


2b. 3 


Set Tax Info 


Portal 


When needed, tax exemption modifications are passed 
with the account POID and associated with the account 
with the PCM_OP_CUSTJET_TAXINFO opcode. 
(This is out of scope for ihub R3.0) 


2b.4 


Acknowledgement 


Portal 


A response will be sent back from Portal to Vitria 
indicating whether the account has been successfully 
modified or not. 
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Se- 
quence 


System Event 


Appli- 
cation 


Description 


1 


Modify Service 


Siebel 


The 'Modify Service" event will be used to send 
changes to a customer's service from Siebel to Vitria. 
The "Modify Service" event will be automatically 
triggered in Siebel to send information to Vitria when 
any of the service information is modified. A Siebel 
Workflow sends the modified service information to 
Vitria in XML format through HTTP protocol 


2a 


Find Customer 


Portal 


Portal uses the account number in the opcode 
PCM OP CUST FIND to determine the account POID. 


2b 


Find Service 


Portal 


Portai will need to retrieve the service poid, using the 
service information sent from Siebel, in order to attach 
the product to the appropriate service. Portal uses the 
opcode PCMJPJEARCH to determine the poid of 
the service. The fnput parameters for 
PCMJPJEARCH are the Service Type, the Service 
Login, anlnline search template built into the opcode's 
input f list 

*Note: In the case that Siebel fails to send service 
information for a defined service-level deal, Portal 
will send back an error to Vitria. 


2c 


Modify Service 


Portal 


Set the service type for the service object in the 
PCM OP CUST MODIFY SERVICE opcode by passing 
it to the service POID and'me INHERITED JNFO array. 
The INHERIT JNFO array contains the effective 
date and service location information. 


2d 


Set Password 


Portal 


Set the service password in 

PCM JP JUST JET JASSWD opcode bypassing it 

the account POID, service POID, and password. 


2e 


Acknowledgement 


Portal 


A response will be sent back from Portal to Vitha 
indicating whether the service has been successfully 
modified or not. 


3a 


Modify Service 
Instance 


Arbor 


This event will be used to modify information related 
to the service instance within Arbor. 


3b 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating whether the service has been successfully 
modified or not. 
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Se- 
quence 


SystemEvent 


Appli- 
cation 


Description ~~ 


1 


Service Status 
Notification 


OMS 


The OMS Source Connector will monitor the OMS 
database to see if there is any change in the status 
of a service or product. If there is a change in the 
status of a service or product, a Service Status 
Notification Event is created with the required parameters. 
The OMS server is accessed to obtain additional 
information. The Service Status Notification Event 
is then sent to the Vitria IOM for handoff to the 
automaton 


2 


Service Status 
Notification 


Vitria 
IOM 


VitrialOM will be responsible for creating and sending 
the Update Product Status Business Event to Siebel 
(lor lhm purposes), vitria luM logic will determine the 
status response to be sent upstream to Siebel. When 
the status is "Active", the Vitria IOM will inform 
Portal! Arbor to begin the billing process. 


3 


Update 
Product 
Status 


Siebel 


The Update Product Status Event will send product 
update information from Vitria to Siebel. Vitria will 
update the CRM application to "Pending" once OMS 
has received a work order. Vitria will also update the 
CRM to "Active" once the order has been successfully 
provisioned in OMS. Vitria will send this information 
to Siebel in XML format via an HTTP protocol. 
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Se- 

/Iff AftAA 


System Event 


Appli- 
cation 


Description 


/ 


Update Account 
Status 


Siebel 


The Update Account Status event sends account status 
information from Siebel to Vitria. The Update Account 
Status event is triggered automatically in Siebel when 
a customer's account status is changed. A Siebel 
worKiiow sdnos uib ndcsssary accouiii iiiiurrnauoii 
to Vitria in XML format via an HTTP protocol. 


n 
£ 


MIA 
NjR 


IDM 
lUlvl 


Tho Annmini Prnoocc R/lnHpl will roroh/P tho 
IIIG MLLUUIIl r/l/ucoo IVIUUcI Will IcLclvti l//c 

updateAccountStatus event and send it off to billing. 
It will wait for a successful acknowledgement event 
in return from the billing applications to be notified 
with me changes are complete in billing. 


3a 


Find Customer 


Portal 


Portal uses the account number in the opcode 
PCM OP CUST FIND to determine the account POID. 


oD 


upoaie Rccouni 
Status 


Dnrfo/ 

rOlldl 


raSS We 3CC0UIH rUlU, SlalUo, blalUo /ray, allU 

defaulted program name to 
PCMJP_CUSTJETJTATUS to set the account 
status to active, suspended, or closed. 


3c 


Acknowledgement 


Portal 


A response will be sent back from Portal to Vitria 
indicating whether the account status has been 
successfully changed or not. 


A - 

4a 


Cease Account 


Arbor 


mis event win be usee to upoaie tne siaws oian 
account to a disconnect requested status by utilizing 
the cease function on the Account API object. 


4h 


RMrtivafp Acnnunt 

FiOGLkiUVCLIv nWjUUItl 


Arbor 


This event will be used to uodate the status of an 
account to a current or active status from a closed 
status by utilizing the reactivate function on the 
Account API object. 


4c 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating whether the account status has been 
successfully changed or not. 
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Se- 
quence 


System Event 


Appli- 
cation 


Description 


1 


Update Product 
Status 


Siebel 


Siebel will send an event to Vitria IOM that will trigger 
the update product event Once. Vitria receives this 
event it will send it on to the provisioning system. 
Vitria IOM will then wait until it receives a provisioning 
request response from the provisioning system (OMS), 
indicating that the event was received. It will then send 
a message onto Siebel letting it know that the request 
has been received. It will then wait for a 
serviceStatusNotification response from the 
provisioning system. Once it has received the 
response it will send the update product Status to 
Siebel to change the status to either complete or 
canceled. 
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Channel Name 


Description 


Business Event 


Publisher 


Subscriber 

*# M mm %m %mm m mm %m f 


AccountChannel 


Events sent to this 


CreateAccount 


Siebel ' 


Account 




channel will pertain to 


ModifyAccount 


Source 


Process 




creating, modifying, 


UpdateAccountStatus 


Connector 


Model 




and disconnecting 


ApplyAccountLevelAojustment 








accounts 


— *• 






Provision 


Events sent to this 


OrderHeader 


Siebel 


Order 


Order 


channel will pertain to 


AddService 


Source 


Processor 


Channel 


installing and 


ModifyService 


Connector 


Model 




disconnecting 


CancelServices 








products and 


AddProduct 








services 


CancelProduct 






ToSiebel 


All events that need 


ServiceStatusNotikation 


Service 


Siebel 




to be published to 


UpdateProductStatus 


Processor 


Target 




the Siebel System 




Model 


Connector 


Provisioning 


All events that need 


ProvisioningRequest 


Service 


OMS 


Bequest 


to be published to 




Processor 


Target 




the Provisioning 




Model 


Connector 




systems 








Provisioning 


All events that are 


ProvisioningResponse 


OMSSource 


Service 


Response 


publishedby 


ServiceStatusUoWication 


Connector 


Processor 




Provisioning systems 




OMSTarget 


Model 








Connector 




Acknowledgement 


All Acknowledgements 


Acknowledgement 


ArborJarget 


Acknowledgement 


Channel 


that an event was a 




Connector 


Mile | 




success or a failure 




Portaffarget 


Service 








Connector 


Processor 








Siebeffarget 


Model ' 








Connector 
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